BEST AVAILABLE COPY 



REMARKS- General 



By the above amendment, Applicant has amended the title to emphasize the novelty of the 
invention. 

5 

Applicant has submitted substitute specifications and drawings which delete irrelevant material 
in order to make the application simpler and easier to read. 

Also, Applicant has rewritten all claims to define the invention more particularly and distinctly 
10 so as to overcome the rejections under 35 USC § 103 and define the invention patentably over 
the prior art. In addition, claims have been reordered to the order in which they were addressed 
in the Office Action. 



The Claims Rejections Under § 103 

Claims 61-131 were rejected under § 103 as being unpatentable over Lazaridis et al in view of 
Herrod et al. because it was said that the combination of these references would be obvious to 
20 one having ordinary skill in the art at the time the invention was made. Applicant requests 
reconsideration and withdrawal of this objection for the following reasons: 



15 



Note: The claimed application file hyperlinks are referred to herein by the name in trade 
"AppLink", as done in the specifications, for ease of reading. 



25 



Prior Art References Incorrectly Interpreted 

Applicant submits that the Office Action has incorrectly interpreted Lazaridis and Herrod 
as being equivalent to the steps of the present invention. The cited references do not teach 
what the Examiner relies upon them as teaching. 



30 



Strained Interpretation of Prior Art 

Applicant submits that the Office Action makes a strained interpretation of the references 
that could have been made only in hindsight. 
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The Suggested Combination Leads to New, Improved, and Unexpected Results 

Even if the interpretations were correct, combining the two references is not an obvious 
step under § 103 because it leads to valuable new, improved, and unexpected results — the 
fact that those skilled in the art have not implemented the invention, despite its great 
advantages, indicates that it is not obvious. 

Commercial Success and Acquiescence 

Applicant's company has achieved commercial success with the suggested combination, 
and commercial acquiescence by licensing AppLink technology to a competitor, as laid 
out in the attached declaration with supporting documents. 

The Claims Rejections Under § 103 

Claims 61-131 were rejected as unpatentable over Lazaridis et al in view of Herrod et al. 

The Examiner has cited other patent and non-patent documents which have not been applied 
against any claim. Applicant has reviewed the references, and found that they do not show the 
claimed invention nor render it obvious. 

The Rejection of Claim 119 

Independent claim 1 19 was rejected on Lazaridis in view of Herrod. Claim 1 19 has been 
rewritten as Claim 132, to define patentability over these references and any combination 
thereof. Applicant requests reconsideration of this rejection, as now applicable to claim 132, for 
the following reasons: 

Lazaridis s "Trigger Event" is Not a Hyperlink 

In Para 3b of the Office Action, the first step of the method of claim 1 19, "detecting the 
activation by the user of a hyperlink associated with the computer file" is considered 



Page 4 



equivalent to Lazaridis, "the redirector program detects a user defined event trigger has 
taken place". 

However, the cited user-defined event triggers are: 

a) not hyperlinks and 

b) not associated with a specific computer file. 

These trigger events are a signal to the redirector host system to initiate redirecting or 
pushing subsequently received files (email and attachments) to the user's current location 
via various devices. Unlike a hyperlink, where action takes place immediately when it is 
activated, nothing happens when an event trigger is received. Only later, when an email is 
received, does something happen. An example demonstrating that said event trigger is 
associated with no files whatsoever is that if no emails are subsequently received by the 
host system after a triggering event, the triggering event will redirect (forward) nothing. 
In fact the triggering event cannot be associated with a particular file since it occurs 
before any file (email or attachment) is received. 

Lazaridis's examples of these event triggers are external events such as receiving a 
command from the user's mobile communication device (Lazaridis, col 7 lines 1 1-13), 
receiving a command from some other external computer (Lazaridis, col 7 line 17), and 
sensing that the user is no longer in the vicinity of the message redirector host system 
(Lazaridis, col 7 lines 18-19). Internal events could be a calendar alarm or screen saver 
activation. Networked events are user-defined messages transmitted to the host system 
via a network to initiate redirection. It can be seen from these examples that Lazaridis' s 
"trigger events" cannot be construed as hyperlinks without an overly strained 
interpretation. Additionally, nowhere in Lazaridis is the word "hyperlink" mentioned as a 
triggering event. 

Lazaridis Teaches Away From a Hyperlink 

Lazaridis' s user defined event trigger cited by the O.A. in Para 3b cannot be interpreted 
as a hyperlink, since the invention of Lazaridis is designed for a single user to access 
his/her own email and attachments. Because a hyperlink can be embedded into a web 
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page or mass-market email, it intrinsically offers third-party, anonymous access. This 
would be contradictory to Lazaridis' s teaching. 

Lazaridis Does Not Teach Operating an Application Program Compatible with the 
Computer File On a Computer Remote to the User 

In Para 3c of the O.A., claim 1 19c-"operating on a remote computer an application 
program associated with the computer file", is considered equivalent to Lazaridis, "a 
remote device", col 6 lines 7-30). In fact, said remote device refers to the user's mobile 
device, such as a cell phone (Lazaridis, "mobile device 24", col 6 line 19; "the remote 
device", col 6 line 24), and not to a computer remote from the user. Sending files to an 
external machine is mentioned by Lazaridis, but examples of this external machine are 
display devices close to the user such as a fax machine or printer local to the user, or to 
storage devices accessible by the user such as video data storage or the user's voice mail 
storage (Lazaridis, col 6 lines 9-13). Operating on a remote computer (that is, remote 
from the user) an application program compatible with or capable of opening the 
computer file is not mentioned anywhere within Lazaridis. 

In fact, since Lazaridis does not detail operating a thin client on the local computer (as 
acknowledged by the O. A., page 3, lines 1-2), there would be no reason to operate an 
application on a remote computer since there would be no way for the user to interface 
with said application program without a thin client. 

Lazaridis's Inbound Email Detection is "Push" Technology, while a Hyperlink is 
"Pull" Technology 

The Office Action asserts that claim 1 19d- "after detection of the hyperlink, opening the 
computer file in the application program running on the remote computer", is equivalent 
to: Lazaridis, the redirector software detects email message using MAPI, col 7 lines 30- 
45. 

However, the Lazaridis reference refers simply to the detection by the host email 
redirection system of new email messages sent to the user. Detection of new email 
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messages is not equivalent to detection of hyperlink activation. Detecting new email sent 
to a user is part of a "push" event, that is, data comes towards the user unrequested. The 
user has no say in the time of occurrence of this event. In contrast, the user activating a 
hyperlink is a "pull" event, that is, data is requested by the user. In this case, the user has 
complete control over the time of the event. 

Lazaridis is "push" technology: Messages and data are automatically forwarded to a user 
as they are received after a trigger event has occurred (Lazaridis, push messages, col 8, 
line 18), whereas the hyperlink in claim 119 (Claim 132) is "pull" technology, where 
access to a file is given when requested by the user. At no time does Lazaridis suggest 
any kind of "pull" mechanism. 

A hyperlink can be activated multiple times. Thus an AppLink to a single file can be 
accessed many times by many people. Conversely, Lazaridis' s email redirection happens 
only once. It cannot happen more than once because the data is forwarded and not 
retained on Lazaridis' s invention. 

Given the fundamental difference between these events, to consider them equivalent 
requires an unduly strained interpretation. 

Lazaridis Does Not Suggest a Thin Client 

The O A. acknowledges that Lazaridis does not explicitly detail claiml 19e- "operating a 
thin client on the local computer, the thin client allowing the user to provide input to and 
receive output from the application program running on the remote computer". The 
Office Action then asserts that Herrod discloses a thin client connected to the Internet to 
upload/download information including email delivery as a thin client (Herrod, a thin 
client, abstract; col 8 lines 1-15; 44-65; col 13 lines 25-47; col 18 lines 33-60; col 20 lines 
31-67). 

Herrod is not a Thin Client as disclosed in the Applicant's Specifications 
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However, the cited thin client operating on a portable device is not connected to the 
Internet; rather it is connected via short-range wireless link to a computer operating 
within a docking mounting device or cradle. Moreover, this "thin client" is rather a 
division of normal computer components into a mobile device with input and display 
5 hardware, and a docking cradle with all other parts: the main processor, memory, etc. 

These two components are connected wirelessly rather than with wires as in a standard 
PC. (Herrod, abstract). The combined machine then accesses email in the normal way. 

In another location, Herrod refers to a thin client as being a web browser capable of 
10 running downloaded "applets" (Herrod, Internet web pages have moved on from being 

static entities viewable using a browser to true applications or applets. Systems have been 
developed. . .in which browser capability is introduced to existing hardware, forming a 
"web top". . .Introduction of such browser allows the user to access the Internet. . .for 
downloading of applications and information..., col 18 lines 33-45). 

15 

Nowhere is there contemplation of a thin client as defined in the Applicant's 
specifications (the web enabling program initiates a communications link with the thin 
client program at 636 and displays the GUI for the application to the AppLink recipient, 
specifications, page 38 lines 13-14). 

20 

Even If Lazaridis And Herrod Were As Asserted, Combining The Two As Suggested In 
Claim 119 Is Unobvious And Hence Patentable Under § 103 

As shown above, Lazaridis and Herrod are not equivalent to the steps of claim 119. However, 
even if they were, the novel steps of claim 1 19 produce many new and unexpected results over 
25 Lazaridis and Herrod, as outlined below. Therefore, reconsideration of claim 1 19 is respectfully 
requested. 

New and Unexpected Results: 

30 AppLink Turns Legacy Applications Into a Means of Communication and 

Collaboration Between the Primary User and Others 
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Remote applications delivered via thin client are known in the art, but they require 
recipients to be members of or subscribers to a service. In contrast, AppLink extends the 
utility of email and the web to software applications. That is, AppLink makes it as easy to 
send an application and a file as it is to send a standard SMTP email or publish a web 
page. The ability of an AppLink in a web page to be clicked upon by a multitude of 
potentially anonymous users turns legacy application programs into a means of 
communication. 

For example, a hyperlink an AutoCAD file and the AutoCAD application can be posted 
on a web page. A web page viewer can click on the hyperlink. Then the AutoCAD 
application, normally used by single workers to create and modify a mechanical design, 
becomes a way to communicate that design to the web page viewer. For the recipient of 
an AppLink, rather than a static image of one side of a design, the full functionality of the 
AutoCAD program is available to rotate, render, zoom in, etc. Additionally, any number 
of collaborators can be given access to the file via AppLink, and can work with the file. 

Applicant's invention solves different problems than Lazaridis-Herrod. There is no 
suggestion in Lazaridis and Herrod of allowing potentially anonymous third parties to 
access applications and files, or to use pull-up native applications as a means of 
communications. 

The Application File Hyperlink Allows Applications Running On Different 
Operating Systems To Be Used As A Means of Communication And Collaboration 

The application running on a remote computer (claim 1 19c) can be running on any 
operating system, regardless of the recipient's operating system. 

AppLink Replaces Email File Attachments and Eliminates Email Attachment Virus 
Danger 

An AppLink URL which links to a file and compatible application can be inserted into an 
email in place of a file attachment. Since no data file is sent to or opened by the user's 
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local computer, there is no danger of the file containing malicious code which will infect 
the user's computer, since its application program does not operate locally. 

With an AppLink, all the virus danger is to the sender (because the AppLinked file is 
opened on a sender's computer), and not the receiver. This is opposite to the normal 
situation, where it is incumbent upon the email receiver to protect himself from 
attachment-borne viruses. 

AppLink Eliminates Email File Attachment Size Limitations 

Many email services have size limitations on email attachments. Email with larger 
attachments are simply blocked. With AppLink, the file is stored on the sender's 
computer, and is never downloaded. AppLink allows access to files of any size instantly 
without download. 

AppLink Allows File Access Even if Email Attachments are Blocked 

In fact, as mentioned in the specifications (page 4), many organizations block all email 
attachments in order to eliminate the virus risk. An AppLink provides a way for a sender 
to give someone at such an organization access to a file such as a presentation without the 
need to send the file as an email attachment. 

File- Viewer Browser Plug-Ins Rendered Unnecessary; AppLinks Have Better 
Function 

A large amount of money is spent by computer application publishers on web browser 
plug-ins which allow application files to be viewed with a web browser, for example a 
PowerPoint viewer built into Internet Explorer. By using claim 1 19's Application-File 
Hyperlink, no plug-in is required, since the application is running remotely. Plus it has 
the advantage that a file sender can ensure that a recipient can view and work with the 
file regardless of which plug-ins the recipient may have installed on his/her web browser. 
AppLinks have better function than browser plug-in file viewers because the full 
functionality of the native program is available for a file viewer. Plug-in file viewers 
usually have a limited subset of the native program's capabilities. 
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Saving large amounts of money and programming time while gaining better capability by 
using AppLinks in place of web browser plug-ins is an argument for the unobviousness 
of this invention. If there is money to be saved, presumably someone would have created 
5 this invention if it were obvious. 

The Rejection of Claim 120 

Independent claim 120 was rejected because the Office Action stated that Lazaridis-Herrod 
10 disclose the hyperlink contains a unique identifier, and associating the unique identifier with 
meta data identifying the computer file (Herrod, URL, col 3 1 lines 25-47). Claim 120 has been 
rewritten as Claim 133, to define patentability over these references and any combination 
thereof. 

15 Applicant requests reconsideration of this rejection, as now applicable to claim 133, for the 
following reasons: 

Herrod Reference Would Function Oppositely to Claim 120 

The Herrod reference cited in the O. A. (Herrod, URL, col 3 1 lines 25-47) suggests giving 
20 a thin client/terminal web server capabilities via a plug-in card to allow other network- 

connected client computers to access data collected by the terminal. 

Claim 120 is the opposite of this. As claimed, the thin client is not the web server but the 
recipient of data over the web. The citation, however, teaches a thin client acquiring, 
25 storing and delivering data over a network, whereas the claim is for a thin client 

receiving data over a network in the form of a remote application, and never storing the 
data locally at all. Therefore, even if the Herrod reference were as asserted by the O. A, 
the suggested combination with Lazaridis would not function as claimed. 

30 Herrod Does Not Refer to a Unique Identifier 
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The Herrod citation does mention a URL, but this suggestion merely refers to the concept 
of a URL linking to server-stored data as presented by a web page, which is well known 
in the art. There is no suggestion in the Herrod citation that the URL or hyperlink contain 
a unique identifier, as claimed. Such an identifier is required to allow the URL to be 
linked or associated with a unique, specific data file, and for other properties associated 
with communication and access to be associated with the file. The Herrod citation is in 
fact for a single URL linked to variable data and multiple files, i.e., whatever happens to 
be in the terminal/web server's data store (Herrod, col 3 1 lines 43-44). 

Also, the Herrod citation makes no mention of meta data associated with said unique 
identifier which identifies the file associated with the hyperlink. Since there is no unique 
identifier, there can be no metadata associated with it. 

Neither Herrod nor Lazaridis contemplate using remote applications as a means of 
communication, therefore they do not teach associating metadata related to that role with 
a file. 

To summarize, claim 120 claims a hyperlink containing a unique identifier which is 
associated with a particular file. An example hyperlink, given in the applicant's 
specifications is: http ://F reeDesk. com/ AppLinks/3 45 .65867.73 645 
As can be readily seen, the example URL is especially suitable to the generation of 
numerous AppLinks, each associated with a specific, individual file. This is opposite to 
the URL cited by Herrod, which is a single URL accessing all data recorded by a remote 
thin client terminal, and further evidence that the suggested combination is a strained 
interpretation. 

The Rejection of Claim 121 

Independent claim 121 was rejected because the Office action stated that Lazaridis-Herrod 
disclose the hyperlink contains a unique identifier, and associating the unique identifier with 
meta data identifying the computer file. Claim 121 has been rewritten as Claim 134, to define 
patentability over these references and any combination thereof 
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Applicant requests reconsideration of this rejection, as now applicable to claim 134, for the 
following reasons as laid out in detail in the discussion of claim 119: 

• Lazaridis's "Trigger Event" is Not a Hyperlink 

• Lazaridis Teaches Away From a Hyperlink 

• Lazaridis Does Not Teach Operating an Application Program Compatible with the 
Computer File On a Computer Remote to the User 

• Lazaridis's Inbound Email Detection is "Push" Technology, while a Hyperlink is 
"Pull" Technology 

Strained Interpretation The purpose of Lazaridis's invention is to forward a data file, 
principally email and attachments, to various external machines (Lazaridis, the present 
invention includes the ability to redirect certain message attachments to. . .an external 
machine which could be a FAX machine, a printer, a system for displaying images or a 
voice mail system, col 6 lines 9-13). It does not teach using server computer applications 
to open the file, therefore it cannot select a server-based application to open the file. 

The claimed invention stores and opens the data file remotely from the recipient and 
explicitly does not forward it. In fact, the whole point of the claim is to not forward a file. 

To suggest that forwarding a data file to a printer close to the user or to a voice mail 
storage system is equivalent to selecting a server-based application to open the file is a 
strained interpretation that could only have been made by hindsight. 



The Rejection of Claim 122 

Claim 122 was rejected because the Office Action stated that Lazaridis-Herrod disclose multiple 
application programs are available to be associated with the computer file, and the associated 
application program is selected based on selection criteria chosen from the group comprising (a) 
legal rights of the user to use the application programs, (b) capabilities of the application 
programs, and (c) properties that are associated with the hyperlink. 
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Claim 122 has been rewritten as Claim 135, to define patentability over these references and any 
combination thereof Applicant requests reconsideration of this rejection, as now applicable to 
claim 135, for the following reasons: 

As detailed above, Lazaridis gives remote access to data items by forwarding them to 
various external machines. Sometimes a copy of said data items is left on the server 
computer. However, this happens when the server computer consists of a user's PC. It is 
left on the PC so that when the user returns, he can access the message with his PC's 
email program. There is no contemplation of giving remote access to that specific data 
file as stored on the server. Rather, remote access is given by redirecting or forwarding a 
copy of the data file to the user's mobile device or to other machines near the user. To 
consider forwarding a data item to an external machine as equivalent to opening it 
internally and is an overly strained interpretation of the reference that could only be made 
in hindsight. 

Lazaridis teaches the exact opposite of the claimed invention in that it sends the file 
onward. It does not open the file in the server. Therefore, Lazaridis does not teach having 
server-based applications available to open the file. 

The claimed invention has a completely different purpose and solves a different problem 
than Lazaridis. As an example, because the purpose of Lazaridis is to forward data to a 
single user, it does not teach evaluating whether the user has legal rights to use a 
particular application (as claimed by the Applicant). Such a step would be entirely 
foreign to Lazaridis (since it is intended to be used by a single user) and demonstrates 
that the claimed invention is substantially different from Lazaridis. 

The Rejection of Claim 123 

Independent claim 123 was rejected because the Office action stated that the claim's "a method 
for handling incoming e-mails at an e-mail gateway" is disclosed by Lazaridis-Herrod (Lazaridis, 
gateway, col 5 line 57-col 6 Hne30). 
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Claim 123 has been rewritten as Claim 136, to define patentability over these references and any 
combination thereof Applicant requests reconsideration of this rejection, as now applicable to 
claim 136, for the following reasons: 



5 Lazaridis' s "Gateway" is a misunderstood reference. The Office action stated that the 

claim's preamble "a method for handling incoming e-mails at an e-mail gateway" is 
equivalent to Lazaridis, gateway, col 5 line 57-col 6 line30. The term "gateway" as used 
by Lazaridis has a very specific meaning which is different from that claimed by the 
Applicant. Lazaridis 5 s gateway refers to a "connection or bridge between the WAN and 

10 some other type of network, such as an RF wireless network, cellular network, satellite 

network, or .(a) land-line connection" (Lazaridis, col 6 lines 2-6). That is, a message 
sent to the user over the Internet (WAN) is forwarded by the redirector by the "gateway" 
pathway, for example to the user's mobile device via RF. In this case, the gateway is the 
connection between the WAN and the RF network. The message gets to Lazaridis' s 

15 server computer, which could be the user's desktop PC, and then is forwarded to some 

external device near the user. 

General Functioning of Lazaridis is Opposite to Claim 123. This is contrary to the 
claimed invention. As claimed, the incoming message is intercepted before it gets to the 
20 user's PC. After stripping off the attachment and substituting an AppLink to the file, the 

email is allowed to continue to the user's PC. No forwarding happens. It ends up at the 
user's PC. 

Lazaridis's gateway is a way to push messages out to the user from the user's PC. Claim 
25 136's gateway is a way to intercept messages going to the user's PC and process them to 

remove virus danger. They end up at the user's PC and go no further. The claimed 
invention solves a completely different problem than Lazaridis, and functions differently. 
This is detailed in a rewritten claim 136 in an added "whereas" paragraph to define the 
invention patentably over the citations, which do not teach what the Office Action relies 
30 on them to teach. 
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Lazaridis's preferred link is not a reference or hyperlink. The Office Action states 
that 7(c) creating a reference associated with the attachment copy is equivalent to 
Lazaridis, email system with preferred link, col 10 line 53-col 1 1 line 6. This is a 
misunderstood reference. Lazaridis's preferred link refers to a data pathway rather than a 
hyperlink or reference. Claim 136 expands reference to: "reference or hyperlink" to 
clarify this. 

Lazaridis does not delete an email attachment. The Office Action states at 7(d) that 
"deleting the attachment from the incoming e-mail and adding said hyperlink to the 
email" is equivalent to Lazaridis, add or delete, col 8, lines 1-30). This is a misunderstood 
reference. When Lazaridis uses the terms add or delete, they refer to the action of adding 
or deleting a message sender or a redirection criteria from a preferred redirector list 
(Lazaridis, add or delete certain senders or message characteristics, col 8 line 23). The 
cited words are not related to attachments or data items. Rather they are related to 
modifying rules for handling data items. 

What Lazaridis does do with the email attachment is to forward it to various external 
devices close to the user. This is opposite to the claim, where the email attachment is 
blocked from getting to the user. Lazaridis does not teach what the Examiner relies upon 
it as supposedly teaching. 

Lazaridis Does Not Operate a File-Compatible Application in a Computer Remote 
from the Recipient. The Office Action states that the step at 7(e) "operating on a remote 
computer remote from the recipient an application program associated with the 
attachment copy", is equivalent to Lazaridis, a remote device, col 6 lines 7-30. In fact this 
reference to a remote computer is to a computer remote from the user's desktop PC, and 
local to the user. This is opposite to the claimed "a remote computer remote from the 
recipient'. The claim is rewritten to replace "application program associated with the 
attachment copy" with "application program associated with and compatible with the 
attachment copy". 
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Lazaridis Does Not Open the File in the Application Running on the Remote 
Computer. The Office Action states that the step at 7(f) "opening the attachment copy in 
the application program running on the remote computer upon activation of the 
hyperlink" is equivalent to Lazaridis, receive and process certain attachments, col 13 
5 lines 20-35. What is meant by Lazaridis 5 s word "process" is filtering and 

redirection/forwarding. The email and attachments are forwarded to an external machine 
local to the user. The cited lines refer to the manipulation of the "push" criteria, that is, 
which messages (filtering) get pushed where (redirection/forwarding). Thus Lazaridis 
does not manipulate data files at the redirection server other than to redirect them and 
10 package them for said redirection. In contrast, the claimed invention, does, in fact ALL 

the processing and working with the file occurs at the server. Claim 123's step f is 
rewritten to replace the word "remote computer" with "computer remote from the 
recipient" to clarify this. 

15 Claim 124 is withdrawn. 

Claim 125 is withdrawn. 

The Rejection of Claims 126 and 130 

20 Claim 126 and 130 were rejected because the Office Action stated that they contain similar 

limitations to the apparatus of claim 123. Therefore, claims 126, 130 are rejected for the similar 
rationale set forth in claim 123. 

Claims 126 and 130 have been rewritten as new Claims 138 and 143, to define patentability over 
25 these references and any combination thereof. Applicant requests reconsideration of this 
rejection, as now applicable to claim 138 and 143, for the reasons detailed above for claim 
123, and for the following reasons: 

Claim 126 Solves Different Problems. Lazaridis solves the problem of forwarding 
30 messages from a user's desktop PC to a mobile users current location. Herrod solves the 

problem of giving a wireless data terminal increased capability. Claim 126 (new claim 
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138), on the other hand, solves the different problem of loss of control of data 
attachments sent to others. Control and protection of outgoing data attachments is 
retained by removing said data from outgoing emails, inserting an AppLink and 
forwarding the email to the recipient's desktop PC, while giving appropriate access to 
recipients via server-based applications delivered via thin client. Rewritten claim 138 has 
added a whereby clause reciting said different problem. 

Claim 130: No Steps Are Taught by Lazaridis-Herrod, Solves Different Problem. 

Claim 130 (new claim 143) claims an AppLink server that has a subset of the features of 
the email gateway claims, that is, the basic capability to react to an AppLink by opening a 
computer file in the remote computer and delivering the GUI output of the application to 
the user via thin client. As explained in the comments above for claim 123, no steps in 
this method are equivalent to Lazaridis-Herrod. The combination suggested by the Office 
Action is not suggested by Lazaridis-Herrod, and is unobvious for reasons detailed in the 
general comments, under New and Unexpected Results. The claimed invention solves 
many problems not contemplated by Lazaridis-Herrod, and such different problems is 
recited in the claim. 

The Rejection of Claims 127 and 129 

Claim 127 and 129 were rejected because the Office Action stated that Lazaridis-Herrod disclose 
imposing file access restrictions on said attachment copy as inherent feature of attachment 
(Lazaridis, email attachment, col 3 lines 35-65). 

Claims 127 and 129 have been rewritten as Claims 138 and 140, to define patentability over 
these references and any combination thereof. Applicant requests reconsideration of this 
rejection, as now applicable to claim 138 and 140, for the reasons detailed above for claim 
123, and for the following reasons: 

As set forth in the comments above for claim 126, the outbound email gateway is a 
patentable innovation with the purpose of protecting intellectual property: i.e., not losing 
control of outgoing data attachments. Claim 127's (new claim 138's) additional step of 
imposing file access restrictions greatly extends this retained control. Because such a 
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purpose was not contemplated by either Lazaridis or Herrod, such a step would not be 
logical for them. The whole point of Lazaridis-Herrod is to give data files more access 
and wider distribution, not less. 

Claim 129 (new claim 140) extends the protection of outbound intellectual property by 
allowing flexible access to data file by recipients based upon various criteria. Less trusted 
persons can get less access under this method. A whereby clause is added to new claim 
140 to explain this: "whereby attachment access can be varied according to the sensitivity 
of a particular attached document." 

The Rejection of Claim 128 

Claiml28 was rejected because the Office Action stated that Lazaridis-Herrod disclose setting a 
variable level of access restrictions based upon a security level associated with the recipient 
(Lazaridis, secure connection, col 6 lines 7-30; secure link, col 7 lines 45-55). 

Claim 128 has been rewritten as Claim 139, to define patentability over these references and any 
combination thereof. Applicant requests reconsideration of this rejection, as now applicable to 
claim 138 and 140, for the reasons detailed above for claim 123, and for the following reasons: 

Misunderstood Reference. Lazaridis' s "secure connection" refers simply to a secure 
data pathway to an external device close to the user (Lazaridis, the present invention 
includes the ability to redirect certain message attachments to. . .an external machine 
which could be a FAX machine, a printer, a system for displaying images or a voice mail 
system, col 6 lines 9-13). 

In contrast, the meaning of security level in claim 128 (new claim 139) is a piece of data 
itself- that is, an evaluation of a level of trust placed in a particular recipient. 

New claim 139 has replaced the words "access restrictions" with "file access restrictions" 
to clarify that the access referred to is associated with the attached file, and not a 
particular data pathway. 
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Inoperative Combination. The cited reference would not function as claimed. To set a 
variable level of access restrictions based on the security of the data pathway associated 
with a particular recipient is not contemplated or claimed. 

Claim 128 extends the protection of outbound intellectual property by allowing flexible 
5 access to data file by recipients based upon various criteria. Less trusted persons can get 

less access under this method. A whereby clause is added to new claim 139 to explain 
this: "whereby attachment access can be varied according to the trust placed in a 
particular recipient individual as represented by said security level." 



10 The Rejection of Claim 131 

Claim 13 1 was rejected because the Office Action stated that Lazaridis-Herrod disclose (a) a 
single server (b) a personal computer; and (c) multiple, separate computers operating as a single 
logical server (Lazaridis, Internet 18, Fig 1). 

15 Claim 13 1 has been rewritten as Claim 142, to define patentability over these references and any 
combination thereof Applicant requests reconsideration of this rejection, as now applicable to 
claim 142, for the reasons detailed above for claim 130 (new claim 141), which demonstrates 
that the AppLink application server claimed is a patentable innovation under 35 USC § 103, 
since few if any of the capabilities of said apparatus are taught by Lazaridis-Herrod, and even if 

20 the cited references were as stated by the Office Action, there is no suggestion that they be 
combined in the way suggested. Therefore, Applicant respectfully submits that the specific 
implementations of the AppLink server as claimed in Claim 131 (new claim 142) are also 
patentable, and Applicant requests reconsideration of this rejection, as now applicable to claim 
142. 

25 

The Rejection of Claim 111 

Claim 1 1 1 was rejected because the Office Action stated that it contains similar limitations set 
forth in apparatus claim 123. Claim 1 1 1 has been rewritten as Claim 143, to define patentability 
over the references stated for claim 123 and any combination thereof. 

30 
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Applicant requests reconsideration of this rejection, as now applicable to claim 143, for the 
reasons detailed above under general remarks and under the discussions of claims 123 (new 
claim 136), and claim 130 (new claim 141). These reasons are summarized below: 



5 Misunderstood References. Lazaridis's preferred link is not a reference or hyperlink. 

Also, Lazaridis does not operate a server-based application on a computer remote from 
the recipient and transmit the graphical user interface of said application to the recipient. 

No suggestion to combine references 

Combining the references is not obvious 

10 Claim 111 Solves Different Problems. Lazaridis solves the problem of forwarding 

messages from a user's desktop PC to a mobile users current location. Herrod solves the 
problem of giving a wireless data terminal increased capability. Claim 111 (new claim 
143), on the other hand, solves the different problem of giving simple and easy access to 
server-based applications to a wide variety of potentially anonymous users. Rewritten 

15 claim 143 has added a whereby clause reciting said different problem. 



The Rejection of Claim 112 

Claim 1 12 was rejected because the Office Action stated that Lazaridis-Herrod disclose (a) 
providing application hyperlink generation means on said computer server system for creating 
20 said application hyperlink and (b) providing application hyperlink transmission means for 

transmitting said application file hyperlink to said at least one recipient user (Lazaridis, Email 
sub system, col 10 lines 20-38). Claim 1 12 has been rewritten as Claim 144, to define 
patentability over the references stated and any combination thereof. 

25 Applicant respectfully requests reconsideration of this rejection, as now applicable to claim 144, 
for the reason that, as detailed in the general comments and the comments about claims 123, 
Lazaridis-Herrod do not teach a hyperlink associated with a thin-client delivered application. The 
Lazaridis citation does refer to a generic email system, but that system is used to transmit data, 
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not applications. Lazaridis-Herrod also address different problems. Claim 112 has been rewritten 
as claim 144 and a whereby clause is added to recite the different problem. 

The Rejection of Claim 113 

5 Claim 1 13 was rejected because the Office Action stated that Lazaridis-Herrod disclose said 
server-based computer application comprises a first communications means consisting of a 
communications program or application (Lazaridis, Email sub system, col 10 lines 20-38). Claim 
113 has been rewritten as Claim 145, to define patentability over the references stated and any 
combination thereof. 

10 

Applicant respectfully requests reconsideration of this rejection, as now applicable to claim 145, 
for the reasons stated below: 

The claimed communication means are operated on a server and the GUI is delivered to 
15 users via thin client. Lazaridis, in contrast, operates every mentioned communications 

method on an external machine near the user, that is, local to and not remote from the 
user. Herrod mentions accessing email over the web, but there is no reference to giving 
access to this application to multiple, potentially anonymous persons. No rational user 
would wish to give others access to their email account. 

20 

However, this objection applies only to a personal communications account, to prevent a 
loss of privacy. It does not apply to the claimed invention, where said communications 
means are not connected to a particular person's account data and message archives. 
Rather, it is a generic account intended to project out to the user the communications 
25 capabilities of the program. The combination of this capability with simple, easy 

hyperlink access, gives the claimed combination the same advantages delineated for 
claim 111. 

Unexpected Results, Solves Different Problem The ability to project out to recipients 
30 virtually any communications application (via thin client), means that they can then use 

that communications application to communicate with the sender, regardless of whether 
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they have that communications program installed locally. Additionally, operating the first 
communications means on the server allows more security for the sender, in that the 
recipient cannot save a copy of a communications session between the sender and the 
recipient (because it is not running locally). 

5 

The Rejection of Claim 114, 115 

Claim 1 14 was rejected because the Office Action stated that Lazaridis-Herrod disclose (a) 
providing a second communications means.. which are compatible with... said first 
communications means, and (b) providing address configuration means on said server system 
10 which allow said communications program to be configured with the communications address of 
said. . .users as inherent features of Internet. Claim 1 14 has been rewritten as Claim 146, to define 
patentability over the references stated and any combination thereof. 

Applicant respectfully requests reconsideration of this rejection, as now applicable to claim 146, 
1 5 for the reasons stated below: 

The ability to project out to recipients virtually any communications application (via thin 
client), preferably preconfigured with the address of the sender, is a novel and 
20 unanticipated ability. 

Claim 1 14 has been rewritten to make clear that it is the thin-client based first 
communications means that can be configured with various addresses. The second 
communications means is not necessarily delivered by hyperlink, and could be the 
25 sender's locally installed communications program. A whereby clause has laid out these 

new and unexpected results. 

Claim 115 (new claim 147) is a narrowing and specific instantiation of claim 1 14, and Applicant 
30 requests reconsideration of claim 1 15 as applied to new claim 147 for the reasons stated above 
for claim 114. 
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The Rejection of Claim 116, 117 and 118 

Claim 1 16 was rejected because the Office Action stated that Lazaridis-Herrod disclose said 
server-based application comprises a computer visual interface desktop work area and further 
5 comprising the steps of (providing one or more native software server-based applications and (b) 
providing access to or links to said one or more native software applications within said 
computer visual interface desktop work area as inherent features of Internet. 

Claim 1 16 has been rewritten as Claim 148, to define patentability over the references stated and 
10 any combination thereof 

Applicant respectfully requests reconsideration of this rejection, as now applicable to claim 148, 
for the reasons stated below: 

15 Misunderstood References. Lazaridis's preferred link is not a reference or hyperlink. 

Also, Lazaridis does not operate a server-based application on a computer remote from 
the recipient and transmit the graphical user interface of said application to the recipient. 

No suggestion to combine references 

Combining the references is not obvious 

20 Claim 116 Solves Different Problems. Lazaridis solves the problem of forwarding 

messages from a user's desktop PC to a mobile users current location. Herrod solves the 
problem of giving a wireless data terminal increased capability. Claim 116 (new claim 
148), on the other hand, solves the different problem of giving simple and easy access to 
server-based applications to a wide variety of potentially anonymous users. Rewritten 

25 claim 148 has added a whereby clause reciting said different problem. 

Claim 1 17 is a narrowing and specific instantiation of claim 116, and Applicant requests 
reconsideration of claim 1 17 as applied to new claim 149 for the reasons stated above for claim 
116. 
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Claim 1 18 is the use of the invention of claim 1 16 in a commercial service, as a business method, 
and Applicant requests reconsideration of claim 1 18 as applied to new claim 150 for the reasons 
stated above for claim 116. 

5 The Rejection of Claim 61 

Claim 61 was rejected because the Office Action stated that it contains similar limitations set 
forth in apparatus claim 123. Claim 61 has been rewritten as Claim 151, to define patentability 
over the references stated for claim 123 and any combination thereof. 

10 Applicant respectfully requests reconsideration of this rejection, as now applicable to claim 151, 
for the reasons detailed above under general remarks and under the discussions of claims 123 
(new claim 136), and claim 130 (new claim 141). 

The Rejection of Claims 63, 64, 65 and 66 

15 

Claim 63 was rejected because the Office Action stated that Lazaridis-Herrod disclose providing 
hyperlink transmission means for transmitting said application file hyperlink to said at least one 
hyperlink recipient user (Herrod, download application, col 18 lines 33-59). 

20 Because the suggested combination does not refer to an application file hyperlink (as detailed 
above in comments about claim 1 19), transmission means for sending said hyperlink are not 
disclosed. Therefore, Applicant respectfully requests reconsideration of this rejection, as now 
applicable to claim 153, for the reasons detailed above. 

25 Claim 64, 65 are reifications of claim 63, and Applicant requests reconsideration as applied to 
new claims 154, 155 for the reasons stated above for claim 63. 

Claim 62 was not rejected and is resubmitted as new claim 152. 
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Claim 66. Applicant requests reconsideration of Claim 66 (as rewritten in new claim 156) for the 
reasons given under claim 119, that is, Lazaridis-Herrod do not disclose a hyperlink as claimed 
in this invention. 



5 Claim 67. Applicant requests reconsideration of Claim 67 (as now applicable to new claim 157) 
because (as detailed above) Lazaridis-Herrod do not disclose a hyperlink as claimed, do not 
disclose associating the hyperlink with a particular file in the first instance, and therefore cannot 
disclose associating it with a different file. 

10 Claim 68. Applicant requests reconsideration of Claim 68 (as now applicable to new claim 158) 
because (as detailed above) Lazaridis-Herrod do not disclose a remote application delivered via 
thin client by activation of a hyperlink. Additionally, Lazaridis-Herrod do not suggest using 
server-based applications as a means of communications, and so would have no reason to modify 
the application user interface settings to optimize such use. To assume this is taught would be a 

15 strained interpretation that could be made only in hindsight. 

Claims 69 and 70. Claims 69and 70 are dependent reifications of claim 61 and Applicant 
requests reconsideration (as applied to new claims 159 and 160) for the reasons stated above for 
claim 61. 

20 

Claim 71. Claim 71 adds variable file access and manipulation restriction means. Because 
Lazaridis-Herrod does not teach or contemplate using remote applications as communications 
means to multiple, potentially anonymous users, and so would have no reason to have variable 
file access or manipulation means. Therefore, Applicant requests reconsideration (as applied to 
25 new claim 161). 

Claims 72-75. Claims 72-75 are dependent reifications of claim 61 and Applicant requests 
reconsideration (as applied to new claims 159 and 160) for the reasons stated above for claim 61 . 
There would be no reason for Lazaridis-Herrod to take the claimed steps and to assume so would 
30 be a strained interpretation. 
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Claims 74-79. The Office Action objections to Claims 74-79 rely on the citation Lazaridis, 
secure connection, col 6 lines 7-30. Applicant requests reconsideration (as applied to new claims 
164-169) for the reasons stated in remarks for claim 128: 

5 Misunderstood Reference. Lazaridis's "secure connection" refers simply to a secure 

data pathway to an external device close to the user (Lazaridis, the present invention 
includes the ability to redirect certain message attachments to. . .an external machine 
which could be a FAX machine, a printer, a system for displaying images or a voice mail 
system, col 6 lines 9-13). 

10 In contrast, the meaning of security level in claim 128 (new claim 139) is a piece of data 

itself- that is, an evaluation of a level of trust placed in a particular recipient. 

New claim 139 has replaced the words "access restrictions" with "file access restrictions" 
to clarify that the access referred to is associated with the attached file, and not a 
particular data pathway. 

15 Claims 71-79. The rejection of Claims 71-79 also relied on the citation Lazaridis, secure 

connection, col 6 lines 7-30; secure link, col 7 lines 45-55. This refers to encrypting a message or 
data file before sending. Claims 71-79 have to do with retaining control of a data file by NOT 
sending it. Applicant therefore requests reconsideration (as applied to new claims 161-169). 

Claim 80 is a dependent claim of claim 63, and is a reification of that claim. Applicant requests 
20 reconsideration (as applied to new claim 170) for the reasons stated above for claim 63. 

Claim 81. Claim 81 is similar to claim 1 16, therefore Applicant requests reconsideration (as 
applied to new claims 171) for the reasons stated in remarks for claim 116. 

Claim 82. Claim 82 was rejected because the Office Action stated that Lazaridis-Herrod 
disclose (a) after detecting said hyperlink activation, assigning a guest account to said recipient 
25 user; and (b) creating a copy of said at least one computer file in the guest account; and (c) 
opening the file copy in said file-compatible server-based application instead of the original 
computer file (Lazaridis, selected item can be replicated, col 6 lines 49-55). 



Page 27 



Applicant requests reconsideration (as applied to new claim 172) for the reasons stated below: 

When the Lazaridis citation refers to replication, it is referring to forwarding the message 
or data item either to the user's mobile device, or to the user's desktop PC. Because there 
is no conception of allowing numerous third (potentially anonymous) parties to access 
5 this data, of course there is no discussion of the security features that a system which 

offers such capabilities should have. The claimed guest accounts provide security by 
providing a "firewall" between an AppLink sender's personal accounts and the "guest" 
account used by the AppLink server. The data item is replicated into the guest account to 
keep AppLink recipients AWAY from the AppLink originator's other data. Lazaridis 
10 does not teach this because the purpose of the Lazaridis invention is to give the user AS 

MUCH access as possible. 

Claims 83-86. Claims 83 through 86 are dependent upon claim 82 and reify and extend that 
invention. Therefore, Applicant respectfully requests reconsideration of these claims as applied 
15 to new claims 173-176, for the same reasons given for claim 82. 

Claim 87. Claim 87 was rejected because the office action stated that Lazaridis-Herrod disclose 
said at least one computer file comprises a first computer file and at least one additional 
computer file, and wherein said application file hyperlink is associated with both the first and the 

20 additional computer files, and comprising the additional steps of (a) operating on a remote 
computer a plurality of application programs, said plurality of programs having at least one 
program compatible with or capable of opening each of said computer files; (b) opening the 
computer files in said plurality of application programs; and (c) transmitting the user interface of 
said plurality of application programs to said thin client means (Herrod, a thin client, abstract; 

25 col 8 lines l-15;44-65; col 13 lines 25-47; col 18 lines 33-60; col 20 lines 31-67). 

Claim 87 is dependent upon claim 61 and is simply a reification of the term at least one computer 
file with a plurality of files. Therefore Applicant requests reconsideration (as applied to new 
claim 177) for the reasons stated in remarks for claim 61. 

30 

Claim 88 is cancelled. 
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Claim 89 is cancelled. 

Claim 90. The Office Action rejection of this claims relied upon Lazaridis, receive and process 
certain attachments, col 13 lines 20-35, as being equivalent to the claimed action of two users 
5 engaged in simultaneous remote collaboration over the same document, they having gained such 
access in the first place by activating an AppLink. Since Lazaridis does not teach any kind of 
simultaneous collaboration, to interpret the citation (which refers only to a user sending 
commands to the PROGRAM, and not other users) as such is an overly strained interpretation 
that could be made only in hindsight. Therefore Applicant requests reconsideration (as applied to 
10 new claim 180). 

Claims 91 & 92. These claims are a business method claim of the invention in claim 61. 
Applicant requests reconsideration of claims 91 & 92 (as applied to new claims 181 & 182) for 
the reasons stated in remarks for claim 61, above. 

15 

Claims 93-96 refers to notification of an AppLink originator whenever someone accesses the 
AppLink, and recording details about such access. Since Lazaridis does not contemplate third 
parties other than the primary user having access to the redirected messages, the notification 
Lazaridis refers to are simply notifications that a new email or message has arrived. There is no 
20 notification for the SENDER of the email that is taught in Lazaridis. Therefore, Applicant 
requests reconsideration of claims 93-96 (as applied to new claims 183-186). 

Claim 97 is similar to claim 131, and therefore Applicant requests reconsideration of claim 97 
(as applied to new claim 187) for the reasons stated in remarks for claim 97, above. 

25 

Claims 98-100 are variations on the possible hardware configurations of claim 61, therefore 
Applicant requests reconsideration of claims 98-100 (as applied to new claims 188-190) for the 
reasons stated in remarks for claim 61, above. 

30 Claims 101-102 refer to different methods to give an AppLink recipient access to a thin client. 
Since Herrod does not contemplate giving thin client access to other than the primary user, 
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Herrod does not consider how to ensure that thin-client based communication occurs, by 
providing multiple ways to get a thin client capability to an AppLink recipient. Therefore 
Applicant requests reconsideration of claims 101-102 (as applied to new claims 191-192). 

5 Claim 103. The Office Action asserted that Lazaridis-Herrod disclose the step of opening the 
computer file occurs only after a determination is made that the hyperlink associated with the 
computer file is still active. The Lazaridis citation, however, refers to a trigger to begin 
redirection (pushing) of subsequently received messages. It teaches nothing about receiving a 
request and evaluating whether the requested file is still accessible. Therefore Applicant requests 
10 reconsideration of claim 103 (as applied to new claim 193). 

Claim 104 refers to associating an AppLink with a different file after the AppLink has been 
created and disseminated. This is required so that an AppLink can function as a subscription 
service, where the content changes periodically. The Herrod reference teaches notifying a user 
15 about the receipt of a message, or playing it back for him. There is no discussion of a changing 
file associated with the same hyperlink. Therefore Applicant requests reconsideration of claim 
104 (as applied to new claim 194). 

Claim 105 is cancelled. 

20 

Claim 106 teaches using an algorithm to select a particular server-based application to use upon 
AppLink activation. Herrod does not contemplate using thin client applications as a means of 
communication, and so does not teach using such an algorithm, which is necessary BECAUSE 
AppLink can give file access to a virtually infinite variety of users, with different security levels 
25 and rights to use various applications. Therefore Applicant requests reconsideration of claim 106 
(as applied to new claim 188). 

Claim 107 is a reification of claim 106, and therefore Applicant requests reconsideration of 
claims 107 (as applied to new claim 197) for the reasons stated in remarks for claim 106, above. 

30 
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Claims 108-1 10 refer to centralized control of various file access parameters in connection with 
using AppLink as a means of communication. Such controls provide protection of intellectual 
property, and this purpose was not contemplated by Lazaridis-Herrod. Therefore Applicant 
requests reconsideration of claims 108-1 10 (as applied to new claims 198-200). 

5 

Conclusion: 

For all of the above reasons, applicant submits that the specification and claims are now in 
proper form and that the claims all define patentability over the prior art. Therefore applicant 
10 submits that this application is now in condition for allowance, which action he respectfully 
solicits. 

If the application is not believed to be in full condition for allowance, applicant respectfully 
requests assistance and suggestions of the Examiner. 

15 Very respectfully, 



James L. Rice 
Applicant Pro Se 
20 2115 Perm Ave S. 

Minneapolis, MN 55405 
Tel 612 963-8233 

Certificate of mailing: I certify that on the date below this document and referenced attachments 
25 will e deposited with the US Postal Service as Express Mail addressed to the Examiner. 




14 feb, 2005 
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standard t e chniqu e is to off e r th e consum e r som e thing valuabl e in e xchang e for p e rsonal 
information. An e xampl e i s a bookstor e discount card which giv e s a purchase pric e discount to 
custom e rs in e xchang e for allowing the company to track th e customer's purchase history. This 
discount, typically 15% or mor e , indicates th e valu e th e company place s on this information. 
The assumption is that th e company can capitaliz e on thi s knowl e dg e by off e ring th e custom e r 
products mor e lik e ly to b e of int e r e st, and thus mor e lik e ly to b e purchas e d. How e v e r, 
limitations of a singl e company' s database arc many: Only larg e customers are abl e to afford th e 
larg e and e xp e nsive e ffort to acquir e and manag e this data. From the custom e r's point of view, 
this information is not availabl e to other bookstor e s, some of which might hav e low e r pric e s or a 
b e tt e r, mor e appropriate s e lection. This information is lost whenever th e company that has 
acquir e d th e data goes out of busin e ss, or p e rhaps is us e d in ways not b e n e ficial to the custom e r, 
such as s e lling custom e r addr e ss e s to junk mail di s tributors. The information is oft e n limit e d in 
scope. For e xampl e , a history of book purchas e s might b e l ess of a pr e dictor of futur e book 
purchas e s than th e fact that a custom e r just l e arned to fly. And that information cannot g e n e rally 
b e acquired in a cost e ffective way by small e r vendors. 

Personal computer and desktop devices, as well as laptop devices, are not capable of 
executing very large scale computer applications consisting of millions of lines of source code. 
Because of their size, such applications require large amounts of memory and relatively high 
cycle speeds of CPU operation in order to run satisfactorily. However, in the 1980's and 1990's, 
with the popularity of the Internet and world-wide web, there has also arisen a general desire to 
have dramatically improved interoperability between systems, as well as improved simultaneous 
communications interfacing and network among an increased number of users. 

Unfortunately, the ultimate providers of the marketing information, i.e., the members of 
the population consisting of the owners of the desktop and laptop PCs in the worldwide 
economies, are generally enslaved by the operating systems or application programs they run. 
This is due to a cost dominance which makes it impractical for most users to switch from one 
system to another once purchased and installed or used in each individual's computing device. 
Similarly, the vendors of the legacy programs, which typically require large investment costs to 
purchase, and may require unique operating systems, have tended to maintain user loyalty by 
coercive practices which provide limited choices to customers. What is needed is a way in 
which various computing platforms may operate in a unified environment. A univ e rsal 
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computing e nvironm e nt may mako it possibl e to provide marketing subj e cts, as discuss e d abovo, 
to regist e r to receive such means to facilitat e transf e r of th e data via th e communication n e ts. 

Within th e fi e ld of computing, th e r e ar e num e rous probl e ms which pr e v e nt effici e nt flow 

of data among computing d e vices. Ind e ed, as th e d e mand for ev e r - larg e r application programs 
continues, and the attendant r e quirement for greater memory to servic e th e s e applications 
accompany such d e mand, s y s t e ms for interfacing and op e rating computing d e vic e s b e com e 
incr e asingly chall e ng e d to k ee p pace. As a result, wh e n e v e r data flow is d e sir e d, for exampl e th e 
download of application or oth e r programs onto computers from a remote computing devic e , 
sub s tantial d e lays typically en s u e which accumulat e to vast aggr e gat e in e ffici e nci es throughout 
the various e conomi e s of th e world. Th e s e in e fficiencies contribut e to a los s of r e sources such as 
time, computing pow e r, human pot e ntial, opportunity costs, and oth e rs. Th ese l e ad to a n ee d for 
more e ffici e nt management and cost -e ff e ctiv e int e rfac e among computing d e vic e s. 

Computing systems or interfaces have been devised which operate in a so-called "thin 
client" mode, i.e., one in which a user terminal or computer may be relatively less powerful than 
a typical existing PC. The thin-client mode of operation may provide for all application 
execution to take place at the server. In this type of thin client, the client acts essentially as a 
terminal emulator, using a commercial network such as the Internet, to submit input to the 
application running at the server level, and displaying the output of the executable resident on the 
server. This mode of operation is comparable to a mainframe terminal. Alt e rnativ e ly, a thin 
client computer may us e th e communications n e twork to obtain application cod e , or other 
ex e cutable code, i.e., programs, to e nabl e application operation at th e thin cli e nt. However, the 
obj e ct cod e of the program is not perman e ntly stored at the thin cli e nt. Typically, if e xecutabl e 
cod e is actually download e d to a cli e nt, only a portion of an application's executable cod e 
r es id e s on the thin client at one time. 

The efficiencies of the thin client mode of operating a computing device stem from the 
manner in which a large size program may be accessed remotely, with the large size program not 
being downloaded to the computing device of the user. Instead, the large program is accessed 
remotely by that computing device user (and likely by other users simultaneously as well). 
Applications have historically been delivered to users over a network by means of a thin client. 
Files have also been transmitted to users over a network via various systems such as FTP, or as 
attachments to an e-mail. Links to web pages or file downloads have similarly been practiced. 
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What would be desirable is a system using familiar user modalities to provide a richly 
functioning interactive and collaborative communications media based at least in part on a 
remotely-executing application. 

Another dev e lopm e nt within th e software industry is incr e asing us e r d e mand and/or 
suppli e r d e sir e for mor e e ffici e nt mod e s of softwar e d e livery to the consum e r, chi e fly through 
softwar e downloads over the ftp or http protocols on th e Int e rnet. Howev e r, while softwar e 
downloads ar e available, users are becoming incr e a s ingly us e d to instant gratification of th e ir 
d e sir e to r e c e iv e digital cont e nt on on - lin e s e rvic e s, without waiting for e xt e nsiv e downloads. Of 
cours e , mod e rn software, born of in - th e- large style programming and consisting of literally 
millions of lines of sourc e cod e , and corr e spondingly larg e e x e cutabl e fil e s following 
compilation, can tak e consid e rable time to download, even on a conn e ction with r e lativ e ly high 
bandwidth, such as DSL or cable modems. Furth e rmore, ext e nsiv e download wait s mak e it 
impractical to switch b e tween a thin - and fat - client environm e nt. 

An additional problem occurs when computer users in locations remote from each other 
attempt to share data files, e.g., word processing "document" files, among themselves. Many 
viruses are spread via e-mail attachments, particularly where the native application for the 
attachment file utilizes macros, i.e., executable code running within the native application that is 
embedded within a data file. Accordingly, as a securing precaution many companies have 
prohibited all e-mail attachments. Furthermore, many Internet Service Providers have file 
attachment size limits of from one to five megabytes, to reduce strain on their infrastructure. It 
would be desirable to provide remote user access to data files of arbitrarily large size without 
sending the file itself, and without the necessity of the recipient ever downloading the file. In 
addition, application interface settings can be customized by the individual, but those settings are 
the same for all documents that person works on. This is depicted in Figure 1 A, (Example of 
existing Windows Application Interface Customization). It would be desirable to provide the 
ability to associate custom interface settings with each file. Finally, large file transmission is 
impractical for users with relatively low-bandwidth connections to a network, such as the 
Internet, particularly when these files do not admit of significant compression. For example, a 
typical analog connection may provide transmission of 56K/second. However, an AutoCAD® 
file for a bridge design might be several hundred megabytes. To download that at 56K would 
actually take days. 
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The originators of some data files may wish to restrict the ability of file recipients to 
change a document. Currently, software exists, e.g. ADOBE®' s Acrobat PDF (portable 
document format) software and client viewer software, and other page-description systems that 
allow data files of certain types to be transmitted in a format which restricts the ability of a 
recipient to make changes to the data file. This file is then sent as an attachment or download to 
the recipient, who then views it if he has the PDF viewer installed on his computer. PDF is 
essentially a "picture" of a document, meaning that the recipient cannot change it. However, a 
data file originator may wish to restrict use or access of a document in other ways in addition to 
restricting modification of a data file. For example, a data file originator may wish to restrict the 
number of times a remote user may view a document, or restrict the ability of a remote user to 
even save the document. It would be desirable to provide a system by which a data file or 
"document" originator may restrict access or permissions to a data file in ways other than merely 
restricting modification. 

Finally, with regard to data file and "document" file sharing, a file originator cannot 
always be certain, without prior consultation with a document recipient, whether the recipient 
has the necessary software, i.e., the data file's native application of the same version used by the 
originator, to view the data file as it appears to the originator. A document originator will wish 
to be sure that a recipient will be able to view, and perhaps work with a data file, regardless of 
whether the recipient has a program capable of opening that file installed on his or her PC. This 
is the function of ADOBE®'s PDF (portable document format). With PDF, a PDF file is derived 
from a document by the ADOBE® conversion utility. However, even with document formats 
such as PDF, the originator does not have complete control over the use put to the document. 
For example, it may be saved by the remote viewer. Also, with PDF, a recipient cannot alter the 
document in any way. 

It would bo d e sirable to provide a thin client computing e nvironm e nt in which us e rs may 
us e softwar e applications in the interim b e tw e en a d e cision to download a software application, 
and th e compl e tion of th e download of the entire body of executabl e code making up the 
application. It would be also desirable to provide a thin client computing environment in which 
collaboration between users may take place, i.e., one in which various users may simultaneously 
view a single data file using a thin-client application. It would also b e d e sirabl e to provide users 
with support for a thin client environment in which a user may work until a "fat client", i. e ., an 
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environment in which ne e d e d application cod e is downloaded and r e side s for an e xt e nd e d period 
of tim e on th e us e r's comput e r, is download e d to th e client computer. 

Summary Of The Invention 

A method is provided by which a user, e.g. a remote user, may access remote files and 
applications in thin client mode by accessing a hyperlink to a URL or network location. This 
hyperlink may be referred to generally herein by the generic term Application File Hyperlink, or 
by the name used in trade "AppLink". A m e thod for improving interfac e effici e ncies betw e en 
network e d or oth e rwise communicating computing d e vic es is provided. Enabling code i s 
provided to e nabl e and/or initiate the int e rfac e b e tw ee n a r e mot e computing d e vic e and a local 
computing devic e . This e nabling cod e is downloadabl e in a format suitable for making pos s ibl e 
substantially instant utilization of th e e nabling cod e , even while additional portions of the 
e nabling cod e continu e to b e download e d to the local computing d e vic e. This enabling code will 
preferably allow terminal emulation by a client compute r, as well as allow further executable 
code to be download e d in th e background, in ord e r to support som e l e v e l of fat - cli e nt support for 
a softwar e application which may b e us e d by the cli e nt us e r. 

In a preferred embodiment of the subject invention, the enabling code provides a terminal 
emulator by which the client computer may access application software resident on a server. 
Preferably, the server computer which executes the application program transmits presentation 
data to the client computer on an instantaneous or near instantaneous basis, so that the terminal 
emulation is transparent to the client user, i.e., so that the experience of the user is similar or 
identical to using a fat client executable application. As th e e nabling cod e and oth e r softwar e 
continues to b e downloaded from th e r e mot e computing d e vic e to th e local computing d e vic e , a 
us e r is fre e to us e other data such as application or fil e data, r e sid e nt at or through e ith e r th e 
r e mot e computing d e vice or th e local computing device. In one embodiment of th e inv e ntion, 
following completion of the download of e nabling data of th e us e r i s , optionally, advis e d of a 
transition s e qu e nc e automatically occurring to t e rminate the application or data download phase 
and fully op e rat e within cither a local computing d e vice mode or a mod e in which fil e s ar e 
shar e d with the local computing d e vic e via the remot e computing d e vic e . 

Also provided within an embodiment of the present invention is a system for distribution 
of data files between and among remote users. In a preferred embodiment of the invention, 
information about the location of a remote server may be embedded in a web page viewed with 
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